The Runtime Complexity (innermost) of the given CpxTRS could be proven to be BOUNDS(1, n^1).

0 CpxTRS
    ↳1 CpxTrsMatchBoundsTAProof (⇔, 21 ms)
    ↳2 BOUNDS(1, n^1)
    ↳3 CpxTrsToCdtProof (BOTH BOUNDS(ID, ID), 0 ms)
    ↳4 CdtProblem
        ↳5 CdtLeafRemovalProof (ComplexityIfPolyImplication, 0 ms)
        ↳6 CdtProblem
        ↳7 CdtUsableRulesProof (⇔, 0 ms)
        ↳8 CdtProblem
        ↳9 CdtRuleRemovalProof (UPPER BOUND(ADD(n^1)), 81 ms)
        ↳10 CdtProblem
        ↳11 SIsEmptyProof (BOTH BOUNDS(ID, ID), 0 ms)
        ↳12 BOUNDS(1, 1)

(0) Obligation:

The Runtime Complexity (innermost) of the given CpxTRS could be proven to be BOUNDS(1, n^1).


The TRS R consists of the following rules:

addlist(Cons(x, xs'), Cons(S(0), xs)) → Cons(S(x), addlist(xs', xs))
addlist(Cons(S(0), xs'), Cons(x, xs)) → Cons(S(x), addlist(xs', xs))
addlist(Nil, ys) → Nil
notEmpty(Cons(x, xs)) → True
notEmpty(Nil) → False
goal(xs, ys) → addlist(xs, ys)

Rewrite Strategy: INNERMOST

(1) CpxTrsMatchBoundsTAProof (EQUIVALENT transformation)

A linear upper bound on the runtime complexity of the TRS R could be shown with a Match-Bound[TAB_LEFTLINEAR,TAB_NONLEFTLINEAR] (for contructor-based start-terms) of 1.

The compatible tree automaton used to show the Match-Boundedness (for constructor-based start-terms) is represented by:
final states : [1, 2, 3]
transitions:
Cons0(0, 0) → 0
S0(0) → 0
00() → 0
Nil0() → 0
True0() → 0
False0() → 0
addlist0(0, 0) → 1
notEmpty0(0) → 2
goal0(0, 0) → 3
S1(0) → 4
addlist1(0, 0) → 5
Cons1(4, 5) → 1
Nil1() → 1
True1() → 2
False1() → 2
addlist1(0, 0) → 3
Cons1(4, 5) → 3
Cons1(4, 5) → 5
Nil1() → 3
Nil1() → 5

(2) BOUNDS(1, n^1)

(3) CpxTrsToCdtProof (BOTH BOUNDS(ID, ID) transformation)

Converted Cpx (relative) TRS to CDT

(4) Obligation:

Complexity Dependency Tuples Problem
Rules:

addlist(Cons(z0, z1), Cons(S(0), z2)) → Cons(S(z0), addlist(z1, z2))
addlist(Cons(S(0), z0), Cons(z1, z2)) → Cons(S(z1), addlist(z0, z2))
addlist(Nil, z0) → Nil
notEmpty(Cons(z0, z1)) → True
notEmpty(Nil) → False
goal(z0, z1) → addlist(z0, z1)
Tuples:

ADDLIST(Cons(z0, z1), Cons(S(0), z2)) → c(ADDLIST(z1, z2))
ADDLIST(Cons(S(0), z0), Cons(z1, z2)) → c1(ADDLIST(z0, z2))
ADDLIST(Nil, z0) → c2
NOTEMPTY(Cons(z0, z1)) → c3
NOTEMPTY(Nil) → c4
GOAL(z0, z1) → c5(ADDLIST(z0, z1))
S tuples:

ADDLIST(Cons(z0, z1), Cons(S(0), z2)) → c(ADDLIST(z1, z2))
ADDLIST(Cons(S(0), z0), Cons(z1, z2)) → c1(ADDLIST(z0, z2))
ADDLIST(Nil, z0) → c2
NOTEMPTY(Cons(z0, z1)) → c3
NOTEMPTY(Nil) → c4
GOAL(z0, z1) → c5(ADDLIST(z0, z1))
K tuples:none
Defined Rule Symbols:

addlist, notEmpty, goal

Defined Pair Symbols:

ADDLIST, NOTEMPTY, GOAL

Compound Symbols:

c, c1, c2, c3, c4, c5

(5) CdtLeafRemovalProof (ComplexityIfPolyImplication transformation)

Removed 1 leading nodes:

GOAL(z0, z1) → c5(ADDLIST(z0, z1))
Removed 3 trailing nodes:

NOTEMPTY(Cons(z0, z1)) → c3
NOTEMPTY(Nil) → c4
ADDLIST(Nil, z0) → c2

(6) Obligation:

Complexity Dependency Tuples Problem
Rules:

addlist(Cons(z0, z1), Cons(S(0), z2)) → Cons(S(z0), addlist(z1, z2))
addlist(Cons(S(0), z0), Cons(z1, z2)) → Cons(S(z1), addlist(z0, z2))
addlist(Nil, z0) → Nil
notEmpty(Cons(z0, z1)) → True
notEmpty(Nil) → False
goal(z0, z1) → addlist(z0, z1)
Tuples:

ADDLIST(Cons(z0, z1), Cons(S(0), z2)) → c(ADDLIST(z1, z2))
ADDLIST(Cons(S(0), z0), Cons(z1, z2)) → c1(ADDLIST(z0, z2))
S tuples:

ADDLIST(Cons(z0, z1), Cons(S(0), z2)) → c(ADDLIST(z1, z2))
ADDLIST(Cons(S(0), z0), Cons(z1, z2)) → c1(ADDLIST(z0, z2))
K tuples:none
Defined Rule Symbols:

addlist, notEmpty, goal

Defined Pair Symbols:

ADDLIST

Compound Symbols:

c, c1

(7) CdtUsableRulesProof (EQUIVALENT transformation)

The following rules are not usable and were removed:

addlist(Cons(z0, z1), Cons(S(0), z2)) → Cons(S(z0), addlist(z1, z2))
addlist(Cons(S(0), z0), Cons(z1, z2)) → Cons(S(z1), addlist(z0, z2))
addlist(Nil, z0) → Nil
notEmpty(Cons(z0, z1)) → True
notEmpty(Nil) → False
goal(z0, z1) → addlist(z0, z1)

(8) Obligation:

Complexity Dependency Tuples Problem
Rules:none
Tuples:

ADDLIST(Cons(z0, z1), Cons(S(0), z2)) → c(ADDLIST(z1, z2))
ADDLIST(Cons(S(0), z0), Cons(z1, z2)) → c1(ADDLIST(z0, z2))
S tuples:

ADDLIST(Cons(z0, z1), Cons(S(0), z2)) → c(ADDLIST(z1, z2))
ADDLIST(Cons(S(0), z0), Cons(z1, z2)) → c1(ADDLIST(z0, z2))
K tuples:none
Defined Rule Symbols:none

Defined Pair Symbols:

ADDLIST

Compound Symbols:

c, c1

(9) CdtRuleRemovalProof (UPPER BOUND(ADD(n^1)) transformation)

Found a reduction pair which oriented the following tuples strictly. Hence they can be removed from S.

ADDLIST(Cons(z0, z1), Cons(S(0), z2)) → c(ADDLIST(z1, z2))
ADDLIST(Cons(S(0), z0), Cons(z1, z2)) → c1(ADDLIST(z0, z2))
We considered the (Usable) Rules:none
And the Tuples:

ADDLIST(Cons(z0, z1), Cons(S(0), z2)) → c(ADDLIST(z1, z2))
ADDLIST(Cons(S(0), z0), Cons(z1, z2)) → c1(ADDLIST(z0, z2))
The order we found is given by the following interpretation:
Polynomial interpretation :

POL(0) = [3]   
POL(ADDLIST(x1, x2)) = x1 + x2   
POL(Cons(x1, x2)) = [1] + x1 + x2   
POL(S(x1)) = [3] + x1   
POL(c(x1)) = x1   
POL(c1(x1)) = x1   

(10) Obligation:

Complexity Dependency Tuples Problem
Rules:none
Tuples:

ADDLIST(Cons(z0, z1), Cons(S(0), z2)) → c(ADDLIST(z1, z2))
ADDLIST(Cons(S(0), z0), Cons(z1, z2)) → c1(ADDLIST(z0, z2))
S tuples:none
K tuples:

ADDLIST(Cons(z0, z1), Cons(S(0), z2)) → c(ADDLIST(z1, z2))
ADDLIST(Cons(S(0), z0), Cons(z1, z2)) → c1(ADDLIST(z0, z2))
Defined Rule Symbols:none

Defined Pair Symbols:

ADDLIST

Compound Symbols:

c, c1

(11) SIsEmptyProof (BOTH BOUNDS(ID, ID) transformation)

The set S is empty

(12) BOUNDS(1, 1)